README.md 3.39 KB
Newer Older
1
# Public Heptapod FOSS instance
2

3
It is hosted at [foss.heptapod.net](https://foss.heptapod.net)
4

5 6 7 8 9 10 11 12
## Administration

This instance is managed by a team of community members, including but not
restricted to people from Octobus and Clever Cloud.

See the [separate page about administration](administration.md)


13 14
## Projects to be imported from Bitbucket

15 16 17 18 19 20
FOSS projects are welcome on foss.heptapod.net, with restrictions primarily
due to the resources being finite.

See
[the announcement](https://heptapod.net/a-public-heptapod-for-free-and-open-source-software.html#a-public-heptapod-for-free-and-open-source-software) for
eligibility criteria and more explanations.
21 22 23 24 25 26 27 28

### Things to be aware of

After import, most issues and merge requests will be owned by the special
"Bitbucket Importer" account.

Heptapod does not support personal forks yet.

29 30 31
### Import test run and validation

We're going to do a test run first, so that the maintainer can verify
32 33
that everything looks good. At this stage, the project will typically be
private.
34 35 36 37 38 39 40 41 42 43 44 45 46

If the maintainer validates the import, two things can happen

1. No significant change (push, issue etc) has happened on Bitbucket side since
   the test run: the maintainer can just switch the project to public.
2. A new import is needed. That probably means the project has some traffic,
   and it's probably a good idea then to decide a switchover time and warn
   contributors in advance that new content created Bitbucket-side will just
   be ignored from that time.
   From there, we can either get back to validating the import, or just make
   it public right away (with basic checking by dev.heptapod.net admins of
   course)

47 48
### Maintainer task list for the import to happen

49 50
Once the Hosting Request is approved, it should be assigned to one of the site-wide
administrators, who will perform the actual import.
51

52
#### Give the assignee explicit membership to the Bitbucket repositories.
53

54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84
This is needed even though they are public anyway.
Nothing more than the read permission is needed: this is just because the
Bitbucket import page lists only repositories of which the user performing the
import is a member.

#### Make sure that your Bitbucket and Heptapod account are tied together.

This is to be sure that you are indeed who you're supposed to be.

In Heptapod, go to your settings, then to the "Account" menu entry. Under
"Social sign-in", if the Bitbucket button displays "Connect", then click it,
you'll be redirected to Bitbucket to review the permissions.
After that you'll be able to log in to Heptapod with your Bitbucket account.


#### Review the [Heptapod workflow](https://heptapod.net/pages/faq.html#workflow).

As a complement to the FAQ, please also read
[Octobus blog post](https://octobus.net/blog/2019-09-04-heptapod-workflow.html)
for motivation about those choices and what they entail.

Keep in mind that while you are not forced to use topics in principle,
branches for Merge Requests originating from Bitbucket forks will be
[imported as topics](https://dev.heptapod.net/heptapod/heptapod/issues/106).
So it's probably a good idea to activate `evolve` and `topic` if you have some
of those, even if you don't use `topic` afterwards.

As the FAQ says, there are settings that can be applied for your projects to
adjust their workflows to your preferences. These are manual administrative
actions that aren't exposed in the web interface. Please get in touch with us
and we'll see what we can do.