As discussed in the comments in PR #1197. Also add documenation
accordingly.
One thing I'm not sure about is the simple check in health.go if the
address is usable in the GET request or not. From reading
https://pkg.go.dev/net#Dial it seems that the only non-standard address
format that would work in the `net` package but not in a GET url would
likely only be `:port`, as the others listed here are actually also
valid urls:
`For TCP, UDP and IP networks, if the host is empty or a literal
unspecified IP address, as in ":80", "0.0.0.0:80" or "[::]:80" for TCP
and UDP, "", "0.0.0.0" or "::" for IP, the local system is assumed.`
One additional thing I noticed is that while `WOODPECKER_SERVER_ADDR`
and `WOODPECKER_SERVER_ADDR` use the default value format of `:PORT`,
`WOODPECKER_SERVER` actually uses `localhost:9000`. I guess it makes a
bit of sense, considering the server might not be local to the agent,
but it looks a bit inconsistent this way. I don't think it would hurt to
make the `WOODPECKER_HEALTHCHECK_ADDR` in this format too, but then it's
different from the server flags again... :-)
closes#1181closes#834
Adds `ignore_failure` to pipeline steps. When it's set to true,
if the step fails the following steps continue to execute as if no failure had occurred.
---
failure enums idea:
* fail (default) = if other steps run in parallel, wait for them and
then let workflow fail
* cancel = if other steps run in parallel, kill them
* ignore = we mark the step as failed but it wont have any impact
This implements #1073, adds .yaml to the accepted endings for woodpecker configs.
This currently adds some more lines to the duplication (tried to compensate by fixing the other duplication in the configFetcher) as the CLI and Server are still separate.
Did used [cspell](https://www.npmjs.com/package/cspell) to find typos and fixed it.
Also add cspell to gitpod.
Signed-off-by: Yarden Shoham <hrsi88@gmail.com>
breakout from #934
when new events are added you don't have to worry that pipeline will behave different as it does now with this
Co-authored-by: Anbraten <anton@ju60.de>
Adding [Gitpod](https://github.com/gitpod-io/gitpod) allows us and others to easily start a complete Woodpecker setup and development cloud IDE. It starts a Woodpecker server, agent and a preconfigured Gitea instance. You can login at Gitea with `woodpecker` and `password`.
* make global environment variables available for pipeline substitution
* lint fixes
* global env support in cli exec; procBuilder tests
* drop GLOBAL_ prefix
* docs
* documentation typo
* Update docs/docs/20-usage/50-environment.md
as suggested by anbraten
Co-authored-by: Anbraten <anton@ju60.de>
Co-authored-by: 6543 <6543@obermui.de>
Co-authored-by: Anbraten <anton@ju60.de>
use yaml aliases (https://yaml.org/spec/1.2.2/#3222-anchors-and-aliases) to have pipeline `variables`
Co-authored-by: qwerty287 <80460567+qwerty287@users.noreply.github.com>
Co-authored-by: Anbraten <anton@ju60.de>
to make it easier for devs to find the right place for code
close#655
Co-authored-by: Anbraten <anton@ju60.de>
Co-authored-by: qwerty287 <80460567+qwerty287@users.noreply.github.com>
Officially support labels for pipelines and agents to improve pipeline picking.
* add pipeline labels
* update, improve docs and add migration
* update proto file
---
closes#304 & #860
Clarify the `when.tag` example:
- The `tag` filter is only used if it's also a `tag` event, so this makes the example clearer for new users.
- mention glob
closes#11
Added support:
1. Environment variable `WOODPECKER_DELETE_MULTIPLE_RUNS_ON_EVENTS` (Default pull_request, push)
2. Builds will be marked as killed when they "override" another build
environment in docker-compose files is an array: lines start with a dash (-) and key value assignments are done using an equal sign (=)
Co-authored-by: 6543 <6543@obermui.de>
- migrate step conditions back into pipeline syntax, but show 2-4 level in toc to be able to see `when` keywords
- create new backend section in admin docs
- update docusaurus
- remove prefix docker of container / container-image where possible
- replace terms SCM, VCS, Github with [forge](https://en.wikipedia.org/wiki/Forge_(software))
- add darkmode favicon variant
With systems like docker swarm or docker compose it is usually a little awkward to manage secrets.
There is no way to directly inject them into the environment config. So you often have to write your secrets directly into the compose file
There are hacky workarounds such as overriding the entry-point of the container and loading a script which then fetches secrets from /run/secrets and replaces the environment variables, but this becomes very difficult once we are using docker images built from "scratch" (which is a really great practice otherwise) as there is no shell or standard tooling available
This adds a *_FILE variant of their Environment config values to work around this issue.
Signed-off-by: Lukas Bachschwell <lukas@lbsfilm.at>
The old docker hub link directs you either to a login page or to your profile. I think it makes more sense to redirect the user directly to available images in the explore tab
* Added documentation of all configuration options.
* sort some flags
* adjust config docs to current flags
Co-authored-by: 6543 <6543@obermui.de>
Co-authored-by: Anton Bracke <anton@ju60.de>
Some flags where unused and / or unnecessary as they are covered by alternatives implemented in PRs of milestone 0.15.0 and just complicated the setup.
closes#681
* use flag value
* fix test
* sed -i 's/STATUS_CONTEXT/WOODPECKER_STATUS_CONTEXT/g'
* docs
* Update docs/docs/91-migrations.md
Co-authored-by: Anbraten <anton@ju60.de>
* correct minor spellings in the docs
* add warning about artifacts not being shared in multi-pipelines
* highlight note on multi-pipelines docs page
* update mentions of GitLab to use its official notation (camel case)
Refactor
- use constants for strings
- more tests
- move constraint code into own package
Enhance
- all constrains use doublestart (glob pattern matching) now
Co-authored-by: Anbraten <anton@ju60.de>
In the Codeberg CI Matrix channel, there was confusion about the `image` specifying Docker containers. I changed some phrases and hopefully made it clearer to new users.
* Add "Stars over time to README
* Move info from README into docs & link to it
* New CI location
* New screenshot
Co-authored-by: John Olheiser <john.olheiser@gmail.com>
Dropped support for `DRONE_*` environment variables in pipeline steps. Pipeline meta-data can be accessed with `CI_*` variables.
- `CI_*` prefix replaces `DRONE_*`
- `CI` value is now `woodpecker`
- `DRONE=true` has been removed
- Creates `Agent Config` with examples of agents and configuration options
- Updates `Pipeline Syntax`
- About the different types of conditionals
- Sort Order (Global -> Step -> Advanced)
- Move Conditional Steps to own page
Co-authored-by: 6543 <6543@obermui.de>
The goal here is to make consistent use of configuration environment variables prefixed `WOODPECKER_`. Where several variants existed, this PR aims to remove all but one option, leaving the most explicit.
This PR only changes server and agent code, but not documentation, in order to keep the PR digestible. Once we have consensus that this is correct, I'll change docs accordingly.
User (rather: admin) facing changes in this PR:
- In general, support for all server and agent config environment variables (env vars) starting with `DRONE_` is removed. The according `WOODPECKER_*` variables must be used instead.
- The env var `WOODPECKER_HOST` replaces `DRONE_HOST`, and `DRONE_SERVER_HOST`.
- The env var `WOODPECKER_AGENT_SECRET` is used to configure the shared secret which agents use to authenticate against the server. It replaces `WOODPECKER_SECRET`, `DRONE_SECRET`, `WOODPECKER_PASSWORD`, `DRONE_PASSWORD`, and `DRONE_AGENT_SECRET`.
- The env var `WOODPECKER_DATABASE_DRIVER` replaces `DRONE_DATABASE_DRIVER` and `DATABASE_DRIVER`.
- The env var `WOODPECKER_DATABASE_DATASOURCE` replaces `DRONE_DATABASE_DATASOURCE` and `DATABASE_CONFIG`.
* docs(status): rewrite
status: changed doesn't exist in the current codebase and the
description was just confusing.
* Use consistent language
Co-authored-by: Anbraten <anton@ju60.de>
Co-authored-by: Nulo <git@nulo.in>
Co-authored-by: Anbraten <anton@ju60.de>
# Config resolution
- pipeline-config setting empty / not specified (default): `.woodpecker/` => `.woodpecker.yml` => `.drone.yml`
- pipeline-config setting defined by user: try that file / folder and no fallback (if a user sets some special value that is normally done for some reason)
# Changes
- pipeline-config setting will be empty by default
- remove fallback setting for config loading (simplifies config)
---
closes#133
---
* adjust config fetching mechanism
* default path empty
* remove fallback flag from ui and db
- Replace mkdocs with docosaurus (improved menu structure, ...)
- Structure docs into `Usage` and `Server Setup / Administration`
- Update favicon
- Create new pipeline-syntax page with all options and links to more detailed docs if available
- Add ci to publish to `woodpecker-ci.github.io`
- Deploy docs preview to surge for review
- Update start-page
Co-authored-by: 6543 <6543@obermui.de>
Example:
```yaml
when:
path: '*.md'
```
should match only builds in which the commit added/removed or modified files with the *.md extension
Co-authored-by: 6543 <6543@obermui.de>