>>steele+7e
This should get you started :D let me know if you need help setting it up https://github.com/reidjs/markdown-tweet-scheduler

>>danpal+O7
In GitLab you can limit concurrency by using a resource group https://about.gitlab.com/blog/2020/01/21/introducing-resourc...

Does that address your need?

Edit with more context: We use CI for deploying to GitLab.com and use resource_group to prevent multiple jobs from running concurrently. What we lack is the ability to prevent multiple pipelines from running concurrently (resource_group is at the job level). It looks like concurrency for actions https://docs.github.com/en/actions/reference/workflow-syntax... can work on groups which is a bit nicer. There is some discussion about making this better for GitLab in https://gitlab.com/gitlab-org/gitlab/-/issues/217522

>>BugsJu+Zf
One relatively simple thing I'd love is the ability to re-run a job where it fails, which is something other CI systems have. On a current project we have some flaky Cypress tests and it sucks to have to re-run the entire workflow from the start when one of the last steps of the job fails. I'm definitely not the only one wanting this [1].

They also offer triggering workflows with 'workflow_run' based on other workflows, but that only happens on the default main branch. We auto build testing environments on each PR and I'd love to be able to have better workflow management based on branches.

[1] https://github.com/actions/runner/issues/432

>>MattGa+fx
You can write custom actions in JavaScript, using the toolkit: https://docs.github.com/en/actions/creating-actions/creating...

However, the workflow referencing the custom action would still be the Actions YAML syntax.

(disclaimer: I work at GH, but not on Actions)

>>duped+Rl
When you edit an action on GitHub, the web editor has support for workflow syntax and will determine if your action is viable before committing. This is even easier if you use the new codespace shortcut (press .) on GitHub.

You might also want to take a look at act which allows you to run github actions locally, this is typically how I do actions development:

https://github.com/nektos/act

I'm curious what prevents you from writing your own actions in typescript now?

>>duped+Rl
This is exactly what I'm working on at https://www.inngest.com. You can write statically typed workflows, run any code as an action (if it runs in a container, or use lambda otherwise), have complex conditionals, and coordinate between events (eg. pause until an event comes in that matches a condition, with TTL paths). There's a debugger to step-over workflows, and see the input/output as it happens. Coming soon, the ability to run actions locally during debug mode.

Workflows are statically typed in that they have event triggers - ideally with an event schema (which we generate for you) - and each "action" has static typing of inputs/outputs (plus additional workflow configuration for reusability). They're defined as code, and can be viewed or edited visually.

It also bundles an event hub, so you can automatically run workflows when events happen in real time. For example, if you want to run a churn flow on signup, create a workflow with a `signup.new` event trigger. The workflows can also coordinate between events, too, so in the churn workflow you can wait for an "interactivity" event from the user for up to 1 day, then time out and run some other flow/logic.

It's workflows, generalised. As if you put Github Workflows, Lambda, Segment, and Zapier in a blender.

If you want early access, you can always reach me at tony [at] inngest.com. I'm rolling out invites every week.

>>yjftsj+gN
We started using Pipeline schedules in my past job to regularly trigger pipelines to e.g. rebuild Docker build images, clear caches and other sorts where you normally need shell access to a cronjob.

https://docs.gitlab.com/ee/ci/pipelines/schedules.html

Similarly, you can trigger pipelines from various angles https://docs.gitlab.com/ee/ci/triggers/ using the API.

If you are looking to combine it with events on-demand, the webhooks may come in handy. https://docs.gitlab.com/ee/user/project/integrations/webhook...

Agreed, some adhoc actions are project specific, though you can programmatically walk through them in API client code, for example searching for a group and triggering all project's pipelines.

https://python-gitlab.readthedocs.io/en/stable/gl_objects/gr... https://python-gitlab.readthedocs.io/en/stable/gl_objects/pi...

>>tonyhb+8R
You should post a Show HN when it's open for people try out. See https://news.ycombinator.com/showhn.html and https://news.ycombinator.com/item?id=22336638. Email me at hn@ycombinator.com with a draft text and I'll look it over for you beforehand. Same offer goes for anyone, just please don't expect a quick reply- that depends on the wild swings of the HN inbox. You can also see how we advise YC startups to do this at https://news.ycombinator.com/yli.html - the logistical parts are YC-only but the communication parts apply to everybody.

>>marius+(OP)
I noticed their hadolint action and couldn't help but think it falls a bit short in terms of flexibility and output. I wrote an action to improve these type of use cases that can be found here: https://github.com/jbergstroem/hadolint-gh-action

>>mtalan+Yk
Looks like someone has built a reusable action for retries: https://github.com/marketplace/actions/retry-step

>>physic+z71
For CI specifically, you should IMO check out https://dagger.io. It abstracts and generalizes CI in exactly the way you need: repeatable, locally runnable, and also cacheable on remote servers. Write once, run anywhere CI - what you have locally will be _exactly_ what runs remotely.

>>xomodo+u61
I don't have any at the moment where a commit to one triggers a build in another, but I have a bunch that run on a schedule, pull code from other repos and do stuff with it.

Best example of that is here: https://github.com/simonw/covid-19-datasette/blob/main/.gith...